@bflad I see you tagged this--thanks! Let me know if you'd be open to the feature, and I'll clean up the patch if so.

Hey @jmcarp 👋 I think in principal this is a good idea, but it might be helpful to see a design sketch of the planned configuration options/usage laid out and discussed in an issue first. There was a similar ask in #3153 (comment), but this is deserving of its own feature request for "Defining ECS Container Definitions in HCL". (I'll likely close out the YAML issue anyways since its not supported by the ECS API and the AWS provider should not concern itself with YAML -> JSON conversion.)

HCL with configuration validation and converting to JSON is a good start, but I think we'll want to look at the problem more holistically as well, e.g. how do I easily add container definition X to Y container definitions?

# Example design sketch - ignoring current aws_ecs_container_definition data source implementation
# Arguably, the existing aws_ecs_container_definition should be migrated to something like aws_ecs_task_definition_container_definition (what a gross name)
# Or preferrably, part of the aws_ecs_task_definition data source in a new container_definitions map with name as the key

data "aws_ecs_container_definition" "monitoring" {
  # name, image, etc.
}

data "aws_ecs_container_definition" "application1" {
  # name, image, etc.
}

data "aws_ecs_container_definition" "application2" {
  # name, image, etc.
}

data "aws_ecs_container_definitions" "service1" {
  container_definitions = [
    "${data.aws_ecs_container_definitions.monitoring.json}",
    "${data.aws_ecs_container_definitions.application1.json}",
  ]
}

data "aws_ecs_container_definitions" "service2" {
  container_definitions = [
    "${data.aws_ecs_container_definitions.monitoring.json}",
    "${data.aws_ecs_container_definitions.application2.json}",
  ]
}

Let's design and discuss this further in the new issue before trying to continue with any implementation. 👍

As mentioned in #5862 (comment) lets work towards a design proposal and then we can consider an appropriate implementation. 👍

That said, Terraform 0.12 does include a new jsonencode() function, which likely alleviates some of the need for a new data source in general except for validation purposes. 😄

This would still be very useful in order to ignore_changes to only select fields, e.g. if you want to deploy a new version of an image outside of Terraform.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!